Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improved ECS attribute and origin translation in awsxrayexporter #1428

Merged
merged 6 commits into from
Nov 5, 2020

Conversation

willarmiros
Copy link
Contributor

Description
Follows up #1360 by translating the relevant ECS attributes from their OTel versions to X-Ray Segment attributes within the aws.ecs block. Also added the two new ECS origins that are derived from the ECS Launch Type. I updated the origin resolution logic to prefer the cloud.infrastructure_service attribute when available instead of guessing the cloud service type based on other predefined attributes. This PR also introduces the cloudwatch_logs field to the AWS translation model, since they are recorded in the ECS resource detector with other services planned.

I will replace all the strings for resource attribute names with more officially defined constants once open-telemetry/opentelemetry-specification#1112 and open-telemetry/opentelemetry-specification#1099 are merged.

Minor changes

  • Updated the origin discovery to return an empty origin if no relevant attributes were discovered, instead of returning the EC2 origin by default
  • Included the cloud.infrastructure_service attribute in the EC2 resource detector. I'll avoid adding it to non-AWS detectors til it's an official attribute
  • Changed ECS resource detector to record Cluster ARN instead of Cluster Name to be consistent with other resources recorded

Testing: Added unit tests/updated existing ones. Also tested end-to-end with a sample ECS app publishing to X-Ray.

Documentation: Updated resource detector Readme for its minor changes.

Copy link
Contributor

@anuraaga anuraaga left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just some small points, thanks

@@ -61,6 +71,8 @@ func makeAws(attributes map[string]string, resource pdata.Resource) (map[string]
switch key {
case semconventions.AttributeCloudProvider:
cloud = value.StringVal()
case "cloud.infrastructure_service":
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As these are destined to be replaced by constants anyways, I'd go ahead and have private constants like AttributeCloudInfrastructureService defined in this file

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's fair, will replace

@@ -163,6 +196,14 @@ func makeAws(attributes map[string]string, resource pdata.Resource) (map[string]
}
}

// Since we must couple log group ARNs and Log Group Names in the same CWLogs object, we first try to derive the
// names from the ARN, then fall back to just recording the names
if logGroupArns != (pdata.AnyValueArray{}) && logGroupArns.Len() > 0 {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need this != even though we have a len check?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I initially didn't have it and it turns out the Len() method relies on an underlying pointer orig in the AnyValueArray struct, so if we don't initialize logGroupArns we get a nil pointer exception. I could check for nilness of orig, but it seemed like an implementation detail that I shouldn't be referencing directly.


// TODO(willarmiros): Only use infrastructure_service for origin resolution once detectors for all AWS environments are
// implemented for robustness
is, present := resource.Attributes().Get("cloud.infrastructure_service")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you can inline, e.g., if is, ok := resource...; ok {

@@ -92,10 +91,10 @@ func (d *Detector) Detect(context.Context) (pdata.Resource, error) {
// The launch type and log data attributes are only available in TMDE v4
switch lt := strings.ToLower(tmdeResp.LaunchType); lt {
case "ec2":
attr.InsertString("aws.ecs.launchtype", "EC2")
attr.InsertString("aws.ecs.launchtype", "ec2")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If it's possible, it'd generally be better to have separate PRs for this processor and the exporter

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, definitely makes sense. In this case I realized some issues with the detector as I was making the exporter changes, and made them side-by-side. In the future I will definitely take care to separate PRs by module.

@codecov
Copy link

codecov bot commented Nov 3, 2020

Codecov Report

Merging #1428 into master will decrease coverage by 0.02%.
The diff coverage is 84.09%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master    #1428      +/-   ##
==========================================
- Coverage   88.72%   88.69%   -0.03%     
==========================================
  Files         344      344              
  Lines       16844    16918      +74     
==========================================
+ Hits        14944    15005      +61     
- Misses       1434     1446      +12     
- Partials      466      467       +1     
Flag Coverage Δ
integration 70.80% <ø> (-0.08%) ⬇️
unit 87.34% <84.09%> (-0.03%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files Coverage Δ
internal/awsxray/tracesegment.go 100.00% <ø> (ø)
...resourcedetectionprocessor/internal/aws/ecs/ecs.go 85.71% <50.00%> (-0.44%) ⬇️
exporter/awsxrayexporter/translator/segment.go 90.16% <60.00%> (-4.39%) ⬇️
exporter/awsxrayexporter/translator/aws.go 99.46% <98.21%> (-0.54%) ⬇️
...resourcedetectionprocessor/internal/aws/ec2/ec2.go 92.00% <100.00%> (+0.33%) ⬆️
...eiver/awsxrayreceiver/internal/udppoller/poller.go 97.61% <0.00%> (-2.39%) ⬇️
receiver/k8sclusterreceiver/watcher.go 97.64% <0.00%> (+2.35%) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 3b7afff...c31c6bf. Read the comment docs.

Copy link
Contributor

@anuraaga anuraaga left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

@tigrannajaryan
Copy link
Member

@willarmiros please resolve the conflicts.

@willarmiros
Copy link
Contributor Author

@tigrannajaryan done, sorry for the delay

@willarmiros
Copy link
Contributor Author

Looks like open-telemetry/opentelemetry-collector#2039 removed some APIs that broke this PR and #1360 which is already merged. I'll get them fixed so the tests pass.

@bogdandrutu bogdandrutu merged commit 86af421 into open-telemetry:master Nov 5, 2020
@willarmiros willarmiros deleted the xray-translate branch November 5, 2020 00:42
dyladan referenced this pull request in dynatrace-oss-contrib/opentelemetry-collector-contrib Jan 29, 2021
ljmsc referenced this pull request in ljmsc/opentelemetry-collector-contrib Feb 21, 2022
…1428)

* adding codeql workfklow

* removing PR and commit triggers

* updating changelog

* removing push trigger

Co-authored-by: Azfaar Qureshi <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants